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The  tragic  shootings  at  Fort  Hood  in  November  2009, 
at  the  Washington  Navy  Yard  in  September  2013,  and 
again  at  Fort  Hood  in  April  2014  have  underscored 
the  need  to  improve  information  sharing  with  partner 
agencies  and  among  installations  across  the  U.S. 
areas  of  responsibility.  During  the  first  two  events 
(findings  from  the  most  recent  Fort  Hood  incident  are 
still  being  analyzed),  installations  in  the  surrounding 
area  were  not  notified;  U.S.  Northern  Command 
(USNORTHCOM)  was  not  notified.  Moreover,  had 
either  of  these  shootings  been  part  of  a  coordinated 
attack,  U.S.  installations  were  unprepared  to 
change  their  force  protection  posture.  In  response, 
USNORTHCOM  developed  a  national  information 
sharing  middleware  to  change  this  dynamic.  Across 
the  country,  organizations  are  able  to  overcome 
technical  challenges  and  institutionalize  information 
sharing  across  disparate  government  and  commercial 
emergency  management  and  force  protection 
systems. 

The  MATADRR  Mission 

Mission  Assurance,  Threat  Alert,  Disaster  Resiliency 
and  Response  (MATADRR)  is  USNORTHCOM’s  joint 
initiative  to  enhance  automated  information  sharing 
and  mission  assurance  by  establishing  information 
sharing  interfaces  across  currently  “stove-piped” 
unclassified  emergency  management/force  protection 
(EM/FP)  applications.  Its  goal  is  to  quickly  disseminate 
time-critical  incidents,  imminent  threats,  and/or  hazard 
information  within  the  USNORTHCOM  Domestic  Area 
of  Responsibility  (AOR)  to  streamline  information 
sharing  through  automation. 

The  Keystone  Solution 

In  response  to  the  requirement  to  more  efficiently 
share  information  without  negatively  impacting  current 
system  investments  and  EM/FP  operations,  the 
MATADRR  initiative  developed  a  middleware  software 
capability  named  Keystone.  Keystone  is  based  on 
the  Unified  Incident  Command  and  Decision  Support 
(UlCDS)  software. 

Keystone  is  a  standards-based  middleware  that 
receives,  translates,  and  transmits  incident  related 
data  between  linked  disparate  systems  to  allow 


a  common  view  between  them.  As  middleware. 
Keystone  does  not  interface  directly  with  end  users. 
Keystone  is  the  transporter  of  uniform  data  in  common 
formats.  Emergency  applications  (sensors,  incident 
logs,  personnel  management,  dispatch  systems,  video 
surveillance  and  intelligence  tools  -  anything  related  to 
homeland  security)  can  provide  a  portion  of  their  data 
to  Keystone,  which  then  publishes  it  to  subscribers’ 
applications.  The  applications  then  see  the  consumed 
data  inside  their  own  user  interface.  Thus,  to  the 
user,  there  is  no  new  application,  no  new  learning, 
and  no  conscious  sending  of  information.  Further, 
Keystone  is  not  intended  to  replace  current  standard 
operating  procedures,  messages  and/or  reports  for 
communicating  emergency  management  and  force 
protection  data.  It  is  intended  to  enhance,  enable  and 
more  quickly  disseminate  emergency  management 
and  force  protection  data  to  a  broader  community 
of  recipients.  Paramount  to  Keystone  success  is  the 
concept  of  improved  local  and  regional  awareness, 
with  simultaneous  national  awareness,  available  to 
decision  makers  at  all  levels  in  between. 

By  using  data  standards,  by  managing  data  content, 
by  ensuring  two-way  sharing  of  data,  by  protecting 
data  ownership,  and  by  defining  the  minimal  fraction 
of  data  needed  for  collaborative  decision  making. 
Keystone  is  allowing  organizations  to  work  within  their 
own  existing  concepts  of  operations  using  their  own 
prior  technology  investments  to  achieve  information 
sharing. 

Purpose 

This  document  describes  the  MATADRR  Keystone 
products  and  related  non-materiel  solutions.  It 
identifies  the  organizations  (with  key  points  of 
contact  [POCs])  using  the  Keystone  solution,  how 
each  customized  the  solution,  and  how  they  agreed 
to  transition  it.  Most  importantly,  this  document 
provides  information  for  obtaining  Keystone  products 
and  support.  Lastly,  the  document  contains  artifact 
information  for  use  in  Defense  Technical  Information 
Center  (DTIC)  for  future  programs  and  projects. 
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2  Transition  Products 


The  goal  of  MATADRR  is  to  share  information  across 
domains,  roles,  functions,  hazards,  and  applications  - 
not  to  create  a  new  application  that  everyone  must  use. 
The  MATADRR  project  uses  the  Keystone  software  to 
provide  true  information  sharing  among  applications 
that  enable  each  individual  application  -  selected  for 
its  intrinsic  value  by  an  end-user  organization  -  to 
acquire  common  data  and  compose  that  data  into  a 
visualization  that  is  appropriate  for  the  end  user 


(Figure  1).  The  application  then  can  further  process 
that  data  and  resubmit  it  for  sharing  with  the  originating 
-  and  other  interested  -  applications.  Keystone  is  not 
one  size  fits  all;  one  application  cannot  meet  all  needs. 
Keystone  builds  many-to-many  relationships  among 
applications  to  meet  the  unique  needs  of  very  diverse 
end-user  communities  created  by  the  Concept  of 
Operations  (CONORS)  the  communities  construct. 


DOD  Emergency  Management  / 
Force  Protection  Communities 


Standards/Working  Groups 


OASIS  » 


Connecting  Cross  Services 
Enabiing  Timeiy 
Horizontai  &  Verticai 
Integration 


Figure  1.  MATADRR  Operational  View 
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Keystone  Architecture  Overview 

The  Keystone  architecture  is  constructed  of  two  main 
web  services:  the  Core  and  the  software  adapters 
(Figure  2).  The  Core  manages  infrastructure  and 
services  while  the  software  adapters  perform  the 
actual  translations.  The  architecture  is  built  on 
service-oriented  principles  using  open  standards.  Each 
Keystone  Core  serves  as  a  local  point  of  integration. 
Keystone  Cores  support  three  varieties  of  services: 
infrastructure,  domain,  and  external.  Infrastructure 
services  enable  the  sharing  of  information  between 
Cores  and  are  based  on  existing,  established  industry 
standards.  Domain  services  provide  for  the  sharing  of 
translated  Information  specific  to  EM/FP,  such  as  all 
hazards  and  threats,  incidents,  command  hierarchies. 


tasking,  and  shared  awareness.  These  services  rely 
on  existing  and  developing  standards  in  the  EM/FP 
domains  -  such  as  those  from  National  Information 
Exchange  Model  (NIEM)  and  the  Organization  for  the 
Advancement  of  Structured  Information  Standards 
(OASIS)  EM  Technical  Committees.  In  addition,  each 
Core  provides  the  ability  to  register  external  services 
using  existing,  developing  and  future  standards. 

Scalability 

A  valuable  feature  of  the  Keystone  architecture  is  its 
scalability.  That  is.  Keystone  can  be  modified  to  serve 
any  type  or  size  of  community.  The  Keystone  Core  can 
be  deployed  as  a  simple  stand-alone  system  for  a  few 
sites  or  as  a  system  of  distributed  networked  Cores. 


Keystone  System  Architecture 
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Figure  2.  Keystone  Architecture 
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Keystone  Core 


Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 


Technology 
Readiness  Level:  6+ 

Deliverables:  Source  code,  software  executable  files, 
business  rules,  documentation  and  information  assurance 
data 

Description 


Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technical  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 


As  stated  previously,  the  Keystone  Core  manages  domain  services  and 
infrastructure  services.  Domain  services  include  incident  management, 
incident  commands,  incident  action  plans,  tasking,  alerts,  maps,  resources, 
and  sensors.  Infrastructure  services  include  agreements,  profiles, 
notifications,  work  products,  directories,  and  broadcasts. 

The  Cores  are  configured  to  support  agreements,  for  the  exchange 
of  data.  Agreements  follow  local  Memorandums  of  Understanding 
(MOUs)  and/or  Mutual  Aid  Agreements  (MAAs)  that  define  the  terms 
and  conditions  under  which  service  component  installations  will  share 
information.  Agreements  must  be  mutually  established  prior  to  data 
sharing  and  enable  dynamic,  all  hazards  and  threats  data  sharing 
topologies. 


Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Deployment 

Keystone  Cores  can  be  installed  on  any  virtual  machine  and  network 
depending  on  the  governance  and  policies  of  the  participating 
organizations.  Cores  can  be  hosted  by  a  government  agency  for  several 
other  agencies,  or  by  a  state  for  many  of  its  local  jurisdictions.  Core 
hosting  can  be  outsourced  for  those  sites  that  do  not  have  the  requisite 
information  technology  infrastructure. 

Keystone  Adapters  and  Interfaces 


s/mm 

V 

Systems  Center 
PACIFIC 


Description 

Keystone  adapters  perform  the  following  functions: 

■  Integrate  other  national  message  sharing  programs  (e.g..  Inte¬ 
grated  Public  Alert  and  Warning  System  [IPAWS],  Federal  Emer¬ 
gency  Management  Agency  [FEMA];  Common  Alerting  Protocol 
[CAP],  Oasis) 


Integrate  commercial  and  government  data  aggregator  applica¬ 
tions  (e.g.,  AtHoc®,  Installation  Protection  Integration  Platform 
[iP2],  Command,  Control,  Communication,  Computers,  and 
Intelligence  Suite  [C4IS],  Non-Secure  Internet  Protocol  Router 
Situational  Awareness  Geospatial  Enterprise  [NIPR-SAGE], 
WebEOC®,  Interface  Control  Document  [ICD]-0101B) 

Provide  two-way  information  sharing  among  commercial  and 
government  incident  management  technologies  to  achieve 
collaborative  decision  making 
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■  Correlate  information  from  all  these  sources  into  defined  incidents, 
meaning  that  all  relevant  information  about  an  incident  can  be 
available  from  one  source  -  Keystone 

■  Provide  content  management  for  information  associated  with  inci¬ 
dents  so  that  connected  applications  know  that  they  are  getting 
the  latest,  authoritative  source  data  available 

How  It  Works 

When  an  organization  installs  Keystone,  it  sets  up  secure  sharing  exchange 
agreements  that  define  how  and  with  whom  it  will  share  its  information.  Data 
owners  continue  to  compose  their  data  as  usual  within  their  own  specific 
system/domain.  Keystone  then  builds  a  defined  incident  about  an  event  by 
compiling  a  series  of  Keystone  Work  Products  composed  of  data  provided 
by  applications  interfaced  to  Keystone  through  the  application’s  Keystone 
Adapter.  The  adapter  authenticates  the  application  to  connect  to  Keystone 
Web  Services  and  translates  the  detailed  data  of  the  application  into  the 
fractional  data  in  a  standard  format  to  be  shared  through  Keystone.  Thus, 
the  Keystone  Work  Product  is  the  basic  unit  of  data  exchange  among 
applications.  Each  application  provides  data  when  it  has  something  to 
contribute  to  the  incident  knowledge  base  and  consumes  a  work  product 
when  it  wants  its  end  user  to  know  about  the  incident. 

All  adapters  can  reside  on  an  Enterprise  Service  Bus  (ESB),  which  provides 
support  for  messaging  reliability,  security,  performance,  and  translation  to 
and  from  standard  formats,  such  as,  CAP,  National  Incident  Management 
System  (NIMS)  and  NIEM.  New  adapters  can  easily  be  added  using  the 
Software  Development  Kit  (SDK). 


Currently  Available  Interfaces  and  Adapters 

A  number  of  adapters  and  interfaces  have  already  been  developed*.  These 
adapters/interfaces  and  the  communities  they  represented  for  the  MATADRR 
project  are  listed  as  follows: 


■  iP2  (Army) 


NIPR-SAGE  (USNORTHCOM) 


■  C4IS  (Navy) 


WebEOC  (Civilian) 


■  AtHoc  (Air  Force) 


ICD-0101B  (prototype) 


‘Development  of  adapters  to  commercial  products  does  not  define  an 
endorsement  by  the  Government  for  these  systems. 


iP2  Adapter 


Contact  Information 

Program  Manager 

USNORTHCOM 

Jorge  Zambrana 

iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Technoiogy 
Readiness  Levei:  6-i- 

Deliverabies:  Source  code,  software  executable  files, 

Army  suggested  business  rules,  documentation  and 
information  assurance  data 

Description 

Installation  Protection  Integration  Platform  (iP2)  is  an  emergency  response 
and  information  management  system  focused  on  the  incident  command 
post  (ICP)  to  emergency  operations  center  interface  with  “All  Hazards” 
capable  functionality.  iP2  provides  an  integration  platform  that  facilitates 
interoperability  and  provides  a  common  operating  picture  (COP)  that 
enables  situational  awareness  for  onscene  response  and  offscene  support 
personnel  during  all  phases  of  incident  management  activities.  The  primary 
operators  of  the  system  are  Department  of  Defense  (DoD)  civilians  to 
include  installation  emergency  management  personnel,  decision  makers 
and  first  responders. 

Client  Type 

Current  R14.01  (iP2  V7.1.2) 
ip2->Keystone  http  connection,  REST  interface 
Keystone->ip2  http  connection,  REST  interface 
R14.06  proposed  (iP2  V7.2.0) 

iP2->Keystone  jms  connection,  tcp  over  SSL,  JAXB  interface,  pub/sub 
topics  -  client  to  broker 

Keystone->iP2  jms  connection,  tcp  over  SSL,  JAXB  interface,  pub/sub 
topics  -  broker  to  client 

Data  Format 

R14.01 

iP2  XML  (see  iP2  API  documents  for  object  model) 

R  14.06  proposed 

JAXB  messaging  objects  (see  iP2  JAXB  data  model) 

Communication  Flow 

■  Create/Update  incidents 

■  Incident  sharing 

■  Plume  sharing 

■  Bidirectional 

•  iP2  to  Keystone  Core 

•  Keystone  Core  to  iP2 
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C4IS  Adapter 


Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 
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Technology 
Readiness  Level:  6-i- 

Deiiverabies:  Source  code,  software  executable  files, 
Navy  suggested  business  rules,  documentation  and 
information  assurance  data 

Description 

Command,  Control,  Communication,  Computers,  and  Intelligence 
Suite  (C4IS)  is  a  SharePoint®  and  web-based  application  that  assists 
the  Navy  shore  command  in  response  to  the  “All  Hazard  Approaches” 
to  threats,  providing  a  multi-tiered  approach  to  developing  Situational 
Awareness  (SA)  in  support  of  the  security,  safety  and  the  integrity  of 
Navy  installations  and  forces. 

The  C4IS  adapter  consists  of  a  mediation  adapter  and  a  Mule-ESB 
adapter.  The  C4IS  adapter  implements  the  “Notice  Type”  type-“ATFP” 
of  Urgent  Notice  messages.  The  mediation  server  is  responsible  for 
the  communication  between  C4IS  system  and  the  Mule-ESB  adapter. 
The  Mule-ESB  adapter  is  responsible  for  the  communication  between 
the  mediation  adapter  and  the  Keystone  Core.  The  mediation  server 
is  transitional  into  the  Keystone  accreditation  boundary  and  will 
eventually  be  merged  as  part  of  the  Mule-ESB  adapter  in  the  future. 

Client  Type 

HTTPS  (Hypertext  Transfer  Protocol  Secure) 

Data  Format 

Urgent  Notice  XML  data  format  sent/receive  between  C4IS/Keystone 

Communication  Flow 

■  Create/Update  incidents 

■  Incident  sharing 

■  Alert  sharing 

■  Plume  sharing 

■  Bidirectional 

•  C4IS  to  Keystone  Core 

•  Keystone  Core  to  C4IS 
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WebEOC  Adapter 


Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Technology 
Readiness  Level:  6+ 

Deliverables:  Source  code,  software  executable  files, 
Civilian  suggested  business  rules,  documentation  and 
information  assurance  data 


Description 

Web  Based  Emergency  Operations  Center  (WebEOC®)  is  a  web-enabled 
and  locally-configurable  incident  and  event  management  system. 

With  access  to  the  Internet,  authorized  emergency  managers  and  first 
responders,  regardless  of  location,  can  enter  and  view  incident  information 
in  WebEOC  status  boards.  WebEOC  enables  users  to  manage  multiple 
incidents  and  daily  events,  assign  and  track  missions  and  tasks,  provide 
situation  reports,  manage  resources,  and  prepare  Incident  Command 
System  (ICS)  and  Incident  Action  Plan  (lAP)  reports.  WebEOC  is  used  by 
federal,  state,  county  and  city  entities. 

Client  Type 

HTTP  Polling 

Data  Format 

WebEOC  XML 

Communication  Flow 

■  Create/Update  incidents 

■  Incident  sharing 

■  Plume  sharing 

■  Bidirectional 

•  WebEOC  to  Keystone  Core 

*  Keystone  Core  to  WebEOC 
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AtHoc  Adapter 


Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Technology 
Readiness  Level:  6-i- 

Deiiverables:  Source  code,  software  executable  files, 

Air  Force  suggested  business  rules,  documentation  and 
information  assurance  data 

Description 

AtHoc  IWSAIerts™  provides  enterprise-class,  network-centric  mass 
notification  and  emergency  communication  systems  customized  for 
military,  government,  healthcare,  higher  education  and  commercial 
organizations.  The  AtHoc  solutions  automate  the  end-to-end  emergency 
communication  process,  delivering  physical  security,  force  protection, 
situational  awareness,  and  personnel  accountability.  Allow  communication 
between  AtHoc  and  other  Emergency  Management  Systems  via  Keystone. 

Client  Type 

AtHoc  ->  Keystone:  HTTP  Post  to  AtHoc  SDK  (polling) 

Keystone  ->  AtHoc:  HTTP  Post  to  AtHoc  SDK 

Data  Format 

AtHoc  XML:  see  AtHoc  SDK  Manual 

Communication  Flow 

■  Create/Update  incidents 

■  Incident  sharing 

■  Plume  sharing 

■  Bidirectional 

•  AtHoc  to  Keystone  Core 

•  Keystone  Core  to  AtHoc 
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NIPR-SAGE  Interface 


Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Technoiogy 
Readiness  Levei:  6+ 

Deliverabies:  Source  code,  software  executable 
files,  USNORTHCOM  suggested  business  rules, 
documentation  and  information  assurance  data 

Description 

U.S.  Northern  Command’s  Situational  Awareness  Geospatial  Enterprise 
(SAGE)  bridges  the  gap  between  disparate  situational  awareness 
systems  by  integrating  critical  infrastructure,  force  tracking,  interagency, 
and  incident  management  data  at  the  unclassified,  NIPRnet  level. 
USNORTHCOM  has  taken  a  full  service  oriented  architecture  (SOA) 
approach  to  providing  data  both  at  USNORTHCOM  headquarters  and 
throughout  the  unclassified  DoD  community  in  support  of  Homeland 
Defense  and  Homeland  Security  efforts. 

SAGE  is  a  robust  Geographic  Information  Systems  (GIS)  architecture 
designed  to  distribute  and  empower  all  USNORTHCOM  Mission  Partners 
with  actionable  geospatial  data  anywhere  in  the  world.  Keystone  implants 
the  Google  Earth  KML  (Keyhole  Markup  Language)  publishing  interface  to 
consume  the  Keystone  Work  Product  sharing. 

Ciient  Type 

Google  Earth  KML  interface 

Data  Format 

Consume  Keystone  Work  Product  XML  data  format 

Communication  Flow 

Unidirectional:  Keystone  Core  to  NIPR-SAGE 
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ICD  01 01 B  Adapter  (Prototype) 


Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Technology 
Readiness  Level:  4+ 

Deliverables:  Source  code,  software  executable  files, 
documentation 


Description 

The  Interface  Control  Document  (ICD)  -  0101 B  (ICD-0101B)  adapter 
prototype  employs  the  Army’s  Security  Equipment  Integration  Working 
Group  (SEIWG)  Extensible  Markup  Language  (XML)  communication 
standard  to  interface  with  multiple  types  of  sensors  messages  via  the 
SEIWG  sensor  emulator.  The  ICD-0101B  adapter  provides  message 
translation  services  by  transforming  SEIWG  formatted  ICD-0101B  device 
status  and  device  incident  XML  messages  into  Keystone  work  products 
such  as  the  incident  and  the  link  work  products  on  the  Keystone  core. 
These  work  products  are  then  shared  via  the  core  to  other  adapters  such 
as  N I  PR  SAGE  and  AtHoc. 

Client  Type 
R14.01 

SEIWG  Emulator  ->  ICD-0101 B  adapter  ->  HTTP  Post  to  Keystone  SOAP 
web  service  ->  External  Clients  (NIPR-SAGE  Google  Earth,  AtHoc) 

Data  Format 

SEIWG  XML  Messages  -  (See  SEIWG  ICD) 

Communication  Flow 

■  ICD-01 01 B  adapter  polls  SEIWG  emulator  for  sensor  events 

■  SEIWG  emulator  sends  sensor  events 

■  ICD-01 01 B  adapter  translates  sensor  event  into  SOAP 
request 

■  Create  work  products  on  Keystone  core 
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Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Keystone  Administrative  Consoie  / 
Agreement  Services 


Technology 
Readiness  Level:  4+ 

Deliverables:  Source  code,  software  executable  files, 
business  rules,  and  documentation 


Description 

The  Administrative  Consoie  is  the  graphical  user  interface  to  the 
Keystone  Core  for  system  administrators.  It  provides  the  means  to 
establish  and  define  relationships  between  Keystone  Cores  and  Keystone 
Adapters  through  their  associated  incident  management  applications.  An 
administrator  can  create  resource  profiles  to  allow  subscription  to  the  data 
in  the  Core;  set  up  sharing  agreements  between  multiple  Cores;  display, 
close  and  archive  incidents  and  work  products;  and  monitor  the  health  and 
status  of  the  Core. 

Agreement  Services  are  enabled  through  the  Administrative  Console. 
Agreement  Services  include  sharing  data  by  incident/event  type, 
specified  incident,  proximity  (range),  and  specific  metadata.  The 
Agreement  Services  are  normally  predefined  and  allow  information 
sharing  relationships  based  on  Mutual  Aid  Agreements,  Memorandums 
of  Agreements,  Memorandums  of  Understanding,  and  other  contractual 
documents  between  organizations. 
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Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Keystone  Software  Development  Kit  (SDK) 

Description 

The  Keystone  Software  Development  Kit  (SDK)  provides  developers  with 
tools  to  develop,  build  and  test  their  application  adapters  with  the  Keystone 
core.  The  SDK  package  provides  code  examples,  as  well  as,  supporting 
documentation,  as  described  below. 

SDK  Documentation 

All  documentation  is  currently  in-progress  and  stamped  DRAFT.  All 
documentation  is  releasable  to  the  DoD  and  U.S.  DoD  contractors  only. 
The  following  is  the  current  list  of  DRAFT  SDK  documents  available: 

■  Architecture  Description  Document  (ADD) 

■  Interface  Design  Description  (IDD)  -  CORE  Only 

■  System-Subsystem  Design  Document  (SDD) 

■  Universal  CONORS 

■  Quick  Start  Reference  Guide 

■  Installation  Guide 

Other  transition  documents  will  include  the  following  documents: 

■  Build  Procedures 

■  Software  Version  Description 

■  Business  Rules  Manual 

■  Software  Release  Notes 

SDK  Request 

An  initial  release  (beta)  of  the  MATADRR  Keystone  Software  Development 
Kit  (SDK)  is  available  upon  request.  To  request  a  copy  of  the  current  SDK 
release,  please  send  an  e-mail  to  Mike  Cazzola  fmichael.w.cazzola@civ. 
mail. mill.  The  e-mail  must  include  the  following: 

■  Your  Name 

■  Your  E-Mail 

■  Your  Phone 

■  Your  Organization  and  Location 

■  Your  Project  Name  and  Government  Sponsor 

■  Technical  POC  Name  (person  who  will  be  receiving 
SDK) 

■  Technical  POC  E-Mail 

■  Technical  POC  Phone 

You  will  be  contacted  with  information  on  the  process  for  receiving  the 
documents  and  support. 
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Contact  Information 

Program  Manager 

USNORTHCOM 
Jorge  Zambrana 
iorae.zambrana@northcom.mil 

719-556-7457 

Transition  Manager 

SPAWARSYSCENPAC 
Doug  Hardy 

doualas.hardv@navv.mil 

619-553-5410 

Technicai  Manager/ 
Performer 

ARDEC 

Robert  Giarratano 
robert.m.aiarratano.civ@mail.mil 

973-724-8096 

Italo  Grasso 

italo.a.arasso.civ@mail.mil 

973-724-8052 


Keystone  Authorization  to  Operate  (ATO) 

The  authority  to  operate  for  Keystone  was  approved  effective  16  January 
2014  with  an  Authorized  Termination  Date  of  15  January  2017.  This 
application  is  approved  as  a  Type  ATO  at  the  MAC  ll/Sensitive  level. 

The  next  step  for  the  Authorization  to  Operate  is  to  generate  the  individual 
packages  for  the  Navy  and  Air  Force  based  on  the  approved  Army 
ATO  Department  of  Defense  Information  Assurance  Certification  and 
Accreditation  Process  (DIACAP)  package.  The  intent  is  to  have  Keystone 
deployable  on  all  NIPR  networks. 

A  Certificate  of  Networthiness  request  was  submitted  on  1 9  February 
2014.  Keystone  passed  its  Network  Enterprise  Technology  Command 
(NETCOM)  analyst  review  and  is  awaiting  signature  by  the  NETCOM 
approving  official. 

Along  with  the  Certificate  of  Networthiness  and  the  Authority  To  Operate 
(ATO),  the  executive  DIACAP  package  will  be  provided  including  the 
following  Information  Assurance  documents: 

■  Certificate  of  Networthiness  (CoN) 

■  Authority  To  Operate  (ATO) 

■  System  Identification  Profile  (SIP) 

■  DIACAP  Scorecard 

■  Information  Technology  (IT)  Security  Plan  of  Action  &  Milestones 
(POA&M) 
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Technology  Transition  Agreements 


The  MATADRR  Technology  Transition  Agreements 
(TTAs)  are  collaborative  documents  between 
the  Product  Agent,  USNORTHCOM  MATADRR 
Operational  Manager,  and  key  Sustaining  Agents 
(e.g.,  typically  programs  of  record  providing  long-term 
maintenance  of  the  product  and/or  components).  The 
key  terms  of  the  agreements  include: 

■  A  list  of  the  specific  products  to  be  delivered 
by  the  Product  Agent. 

■  Any  known  critical  gaps  or  capability  short¬ 
falls,  and  their  fixes  (within  budget  and 
schedule  constraints)  before  the  product 
delivery  will  be  accepted  by  the  Sustaining 
Agent. 

■  Any  acceptance  events  defined  by  the 
Product  Agent  and  Sustaining  Agent  (e.g.. 
Technical  Demonstrations,  Independent 
Verification  and  Validation  [IV&V]  events. 
Operational  Utility  Assessments). 

■  A  projected  timeline  for  the  final  acceptance 
and  transition  of  the  product  to  the  Sustain¬ 
ing  Agent. 


Transition  Partners 

A  MATADRR  TTA  was  signed  between 
USNORTHCOM  and  JPM  Guardian  on  12  July  2013 
to  transition  the  Keystone  product.  Other  TTAs  were 
drafted  and  a  final  draft  has  been  staffed  with  the  US 
Fleet  Forces  Command  pending  further  definition 
and  refinement  of  the  Concept  of  Employment 
documentation. 

More  recently  a  letter  has  been  staffed  from 
USNORTHCOM  to  the  JPEO-CBD  to  endorse  JPM 
Guardian  as  the  Joint  Product  Office.  Therefore,  it  is 
now  the  intent  of  MATADRR  Management  to  provide 
Letters  of  Transmittal  to  provide  the  Keystone  product 
to  the  existing  Transition  Partners  as  noted  in  the  table 
below. 


Figure  3.  JPMG  TTA 
Signatories 


ORGANIZATION 

TRANSITION  PARTNER 

TRANSITION 

OWNER 

TRANSITION  AGREEMENT 

U.S.  Army 

Joint  Project  Manager 
Guardian  (JPMG) 

Ms.  Karen  House 

Technology  Transition  Agreement 
(TTA) 

U.S.  Navy 

Fleet  Forces  Command 
(NAVNORTH) 

CDR  Paul  Bunnell 

Draft  TTA,  Transmittal  Letter 

National  Guard 
Bureau 

Command,  Control, 
Communications,  and 
Computers  Directorate 
(J-6) 

LTC  Tim  Pettit 

Transmittal  Letter 

U.S.  Air  Force 

Headquarters  Air  Force 
(A-4/7) 

Lt  Col  William 

Lowery 

Transmittal  Letter 
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Deliverables 


KEYSTONE  PRODUCT  DELIVERABLE  PACKAGE 


Software 

■  Keystone  Source  Code* 

■  Executables 

Documentation 

SDK  Documents 

■  Architecture  Description  Document  (ADD) 

■  Interface  Design  Document  (IDD)  -  Core  Only 

■  System  Subsystem  Design  Document  (SDD) 

■  Quick  Start  Reference  Guide 

■  Installation  Guide 

■  Universal  CONORS 

Information  Assurance  Documents 

■  Army  DIACAP  Package 

■  Army  CoN  Package 

■  Army  ATO  (Authority  to  Operate) 

Other  Documents 

■  Software  Version  Description 

■  Build  Procedures 

■  Software  Release  Notes 

■  Test  Procedures,  Scripts,  Scenarios,  Data 

■  Business  Rules  User’s  Manual 

Training/Product  Support 

■  Training  Materials  (Briefing  Slides,  Usage  Scenarios) 

■  Product  Support  (Help  Desk  process  and  information) 

*ln  accordance  with  the  ATO,  ARDEC  is  responsible  for  the  integrity  of  the 
software  code.  Therefore,  the  Keystone  software  code  shall  remain  under 
ARDEC’s  Configuration  Management  Control. 
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Transition  Acceptance  Events 


This  section  outlines  Keystone’s  move  from  the  science 
and  technology  (S&T)  development  stage  to  a  product 
ready  to  be  used  in  an  operational  environment:  ready 
to  prevent/respond  to  an  incident  or  to  alert/receive 
alerts  from  other  partners.  Acceptance  events  were 
increasingly  operationally  focused  demonstrations 
and/or  exercises  intended  to  improve  the  transition 
readiness  of  the  software  to  the  receiving  program. 

In  the  end,  successful  test  and  assessment  reports 
led  to  a  product  acceptance  letter  between  the  TTA 
organizations,  indicating  the  receiving  program’s 
intention  of  integrating  the  Keystone  product  into  its 
software  baseline. 

Technology  Demonstration 
(Ft.  Belvoir) 

The  MATADRR  Technology  Demonstration  took  place 
on  25  June  2013  in  Fort  Belvoir,  VA.  The  demonstration 
went  as  planned;  the  Keystone  Cores,  adapters  and 
five  emergency  management  applications  operated  as 
expected. 

Demonstration  Scenario 

The  demonstration  scenario  was  based  on  an  incident 
at  Fort  Belvoir,  VA,  in  which  a  tank  truck,  carrying  fuel, 
explodes  near  the  Pence  Gate  (the  main  entrance 
to  Fort  Belvoir).  The  flames  from  the  truck  spread, 
creating  a  large  fire  and  plume  cloud  at  the  gate  that 
spread  to  the  surrounding  area  including  U.S.  Route  1. 


■  The  Army  IP2  system  transmitted  an  Incident 
Message  with  a  plume  model.  This  informa¬ 
tion  was  then  shared  across  services  with 
the  local  Navy  and  Air  Force  respective 
emergency  management  systems. 

■  The  Air  Force  system  for  this  demonstra¬ 
tion,  AtHoc,  transmitted  a  notification  text 
message  (which  was  converted  to  speech) 
to  select  telephone  (cellular  and  landline)  as 
a  personnel  notification  method  for  the  Air 
Force. 

■  The  Navy  C4IS  system  transmitted  a  notifi¬ 
cation  as  an  urgent  message  to  the  affected 
Navy  areas. 

■  At  a  higher  echelon,  USNORTHCOM’s 
situational  awareness  NIPR-SAGE  system 
received  the  incident  information  by  receiving 
a  URL  link  to  the  incident  and  plume  model 
information,  where  it  was  added  to  the  NIPR- 
Sage  MATADRR  menu.  Users  with  the  proper 
access  ID  were  able  to  access  the  NIPR- 
Sage  plume  model  link  via  Google  Earth. 

■  And  because  of  potential  impact  to  the 
local  county,  the  information  was  shared  to 
WebEOC  representing  Fairfax  County’s  EM 
system  (local  civilian  first  responders). 

Figure  4  depicts  the  information  flow  of  data  within  the 
MATADRR  construct  for  this  demonstration. 


Figure  4.  Technology  Demonstration  Data  Flow 


There  were  approximately  50  people  in  attendance 
for  the  demonstration.  The  feedback  regarding  the 
concept  and  application  was  positive:  “MATADRR 
is  already  where  we  need  other  systems  to  be  in 
the  purple  (Joint)”  -  Colonel  Dennis.  Constructive 
feedback  was  mostly  related  to  the  complexity  of  the 
demonstration  and  suggestions  for  improvement. 

The  MATADRR  web  site  (http://www.matadrr.orgf 
contains  a  video  (Figure  5)  from  that  demonstration 
showing: 

■  How  MATADRR  shares  information  across 
services  (iP2,  C4IS,  AtHoc,  WebEOC,  and 
NIPR-SAGE) 

■  Scalability  of  information,  by  transferring 
information  across  multiple  Keystone  Cores 

■  Examples  of  MATADRR  business  rules  which 
are  the  tools  of  content  management 


Figure  5.  MATADRR  Demonstration  Video 


Independent  Verification  Test  (San  Diego) 

The  MATADRR  Independent  Verification  Test  (IVT)  took  place  from  18  February  to  14  March 
2014  in  San  Diego,  CA.  It  consisted  of  the  MATADRR-developed  Keystone  Cores  and  Keystone 
Adapters,  along  with  third-party  applications  (Figure  6).  Additions  to  the  IVT,  that  went  beyond 
the  original  Technical  Demonstration  at  Ft.  Belvoir,  included  updates  to  AtHoc  and  WebEOC 
applications,  and  an  ICD-0101B  prototype. 


'AtHoc 
V  6.1.8 


C4IS 
V  4.1 


IP2 

vSP7 


^EIWG 

Emulator 


WebEOC 

v7.4 


Picatinny,  NJ 


KS  =  Keystone 


Arlington,  VA 


Figure  6.  MATADRR  IVT  Test  Architecture 
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For  this  test  and  demonstration  event,  one  Keystone 
Core  and  aii  of  the  Keystone  Adapters  were  depioyed 
at  Armaments  Research  Deveiopment  and  Engineering 
Center  (ARDEC),  Picatinny  Arsenai,  NJ.  This 
demonstrated  the  hub-spoke,  ciient-server  type  of 
architecture.  Another  Keystone  Core  was  depioyed  at  a 
contractor  faciiity  in  Ariington,  VA.  Muitipie  Cores  were 
used  to  demonstrate  the  scaiabiiity  and  peer-to-peer 
type  of  architecture. 

Aii  third-party  appiications  were  depioyed  at  different 
iocations  across  the  country  as  indicated  by  biue  dots 
on  the  associated  map  (Figure  7).  These  appiications 
inciuded  iP2,  C4iS,  AtHoc,  WebEOC,  and  NiPR- 
SAGE.  Aii  communications  across  the  appiications 
were  done  through  the  Keystone  Adapters,  which 
utiiized  Keystone  Cores  to  share  information.  Aii 
communications  were  bi-directionai,  with  the  exception 
of  the  NiPR-SAGE  appiication  that  oniy  received  data 
(KML). 


Aii  iVT  Testers  and  Operators  were  operating  from  San 
Diego  and  utiiized  the  web  ciients  of  each  appiication 
to  send  and  receive  information.  The  Testers  and 
Operators,  whiie  iocated  in  San  Diego  for  this  event, 
couid  have  been  geographicaiiy  dispersed. 

The  iVT  conciuded  on  14  March  2014.  initiai  findings 
indicated  that  98%  of  test  cases  were  successfui,  with 
no  immediate  or  urgent  probiem  change  requests. 
Business  ruies  were  tested,  end-to-end  scenario  tests 
were  executed  in  preparation  for  the  Finai  Transition 
Demonstration  (FXD),  and  the  Joint  interoperabiiity 
Test  Command  (JiTC)  successfuiiy  coiiected  their  data 
for  interoperabiiity  assessment.  The  officiai  resuits  from 
the  iVT  wiii  be  avaiiabie  in  eariy  May,  and  the  JiTC 
assessment  is  scheduied  for  mid-May. 
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Joint  Interoperability  Test  Command  (JITC) 
Assessment 

A  JITC  representative  joined  the  Testers  near  the 
end  of  the  IVT  and  began  collecting  log  data  from  all 
communications  between  Keystone  Cores,  Keystone 
Adapters,  and  the  native  EM  systems.  After  the  IVT 
and  FXD,  this  data  will  be  further  analyzed  in  terms  of 
interoperability  and  standards,  and  the  results  will  be 
provided  in  a  JITC  Assessment  Report.  This  Product 
Reference  Guide  was  submitted  prior  to  the  results 
of  the  JITC  Assessment  Report  being  available  in 
May  2014.  Information  is  available  by  request.  Please 
contact  Ms.  Peggy  West,  peggy.west@us.army.mil. 


Final  Transition  Demonstration 
(FXD)  (San  Diego) 

After  a  month-long  IVT  that  finished  with  an  End-to-End 
(E2E)  System  Test  and  a  Joint  Interoperability  Test 
Command  (JITC)  Assessment,  the  FXD  took  place 
from  17-20  March  2014.  It  was  the  culmination  of 
a  USNORTHCOM  operationally  sponsored  project 
addressing  identified  DoD-wide  information  sharing 
gaps.  Over  the  course  of  three  days,  operator, 
technical,  and  observer  feedback  was  collected  and 
a  final  Operational  Utility  Assessment  (OUA)  was 
performed. 


Figure  8.  FXD  Kickoff  Instructions  for  Operators,  Subject  Matter 
Experts,  and  Assessors 
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Uniformed  and  civilian  operators,  subject  matter 
experts,  senior  observers,  operational  assessment 
analysts,  and  key  stakeholders  observed  the 
Operational  Utility  and  User  Feedback  event  conducted 
during  the  FXD  and  assessed  first-hand  the  value 
added  in  the  automated  near  real-time  sharing 
of  information  supporting  Force  Protection  and 
Emergency  Management  mission  essential  functions. 

A  series  of  scenarios  and  vignettes  were  used  to 
exercise  the  EM/FP  systems  through  the  MATADRR 
Keystone  middleware.  Scenarios  included  terrorist 
events  (a  gate  runner  combined  with  a  chlorine 
tanker  truck  explosion  and  a  Mumbai-style  attack  with 


multiple  shooters)  and  natural  disasters  (a  hurricane 
along  the  eastern  seaboard  and  an  earthquake). 

Linked  by  Keystone,  the  previously  disparate  systems 
demonstrated  the  ability  to  share  information  and  data, 
and  display  it  on  their  respective  situational  awareness 
displays.  Figure  9  demonstrates  the  power  of 
Keystone:  all  five  systems  In  the  FXD  display  a  plume 
that  was  generated  after  a  chlorine  tanker  explosion 
and  a  subsequent  chemical  plume  drifting  southwest 
from  the  origin  of  the  explosion.  Without  Keystone  to 
initiate  the  exchange  of  data,  these  five  systems  cannot 
and  do  not  inherently  share  information. 


AtHoc 


Connecting  existing  systems 
Consistent  data  exchange 


Figure  9.  Keystone— Information  Sharing  Across  Systems 


-s:cr 
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FXD  Outcomes 

■  Initial  findings  indicate  that  planned 
Keystone  functionality  in  an  operationally 
relevant  environment  performed  as  expect¬ 
ed,  and  information  was  shared  between 
disparate  systems  in  near  real  time. 

■  Critical  feedback,  comments  and  recom¬ 
mendations  were  collected  for  prioritization 
and  incorporation  into  the  next  version  of 
Keystone. 

■  Several  capabilities  were  captured  for  future 
enhancements. 

■  The  FXD  identified  the  need  for  more 
in-depth  conversations  with  the  services 
and  key  stakeholders  regarding  concepts 
of  employment  and  tactics,  techniques  and 
procedures  (TTPs). 

Joint  Test  and  Assessment  Group  (JTAG) 
Operational  User  Assessment  (OUA) 

Prior  to  the  release  of  the  full  OUA  report  in  early  May, 
the  JTAG  provided  an  FXD  Quick  Look  Assessment 
Report  in  early  April.  Key  points  are  as  follows: 


■  Initial  findings  indicate  that  all  planned 
Keystone  functionality  performed  as 
expected. 

■  Initial  responses  from  operators/analysts  and 
subject  matter  experts  were  positive. 

■  Overall,  users  were  satisfied  with  the  func¬ 
tionality  Keystone  provided. 

■  Increased  information  sharing  brought  into 
focus  the  need  for  established  business 
rules. 

■  Development  of  business  rules  is  critical 
to  successful  deployment  of  Keystone 
capability. 

■  Initial  feedback  suggests  Keystone  will 
improve  situational  awareness  and  decision 
making  for  emergency  management  and 
force  protection  communities. 

This  Product  Reference  Guide  was  submitted  prior 
to  the  release  of  the  final  JTAG  Operational  User 
Assessment  Report.  Information  is  available  by 
request.  Please  contact  Ms.  Peggy  West,  peggy. 
west@us.army.mil. 
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There  were  approximately  50  visitors  participating  in 
a  variety  of  ways  to  support  the  FXD.  A  key  transition 
partner  stated,  “I’m  amazed  at  how  far  along  the 
MATADRR  team  got  within  the  18  months  timeframe. 
What  a  great  capability.”  -  Ms.  Karen  House.  Key 
stakeholders  and  participants  are  pictured  below 
(Figure  1 1)  at  Space  and  Naval  Warfare  Systems 
Center,  Pacific  (SPAWARSYSCENPAC)  in  San  Diego, 
CA,  including  representatives  from: 

■  USNORTHCOM 

■  Air  Forces  Northern  (AFNORTH) 

■  Army  Northern  (ARNORTH) 

■  Physical  Security  Enterprise  and  Analysis 
Group  (PSEAG) 

■  Commander  Navy  Installations  Command 
(CNIC) 


■  United  States  Fleet  Forces  Command 
(USFF) 

■  Commander  Navy  Region  Southwest 
(CNRSW) 

■  National  Guard  Bureau  (NGB) 

■  Armaments  Research  Development  and 
Engineering  Center  (ARDEC) 

■  Engineer  Research  and  Development  Center 
(ERDC) 

■  San  Diego  County  Emergency  Operations 
Center  (EOC) 

■  Carlsbad  Fire 

■  Encinitas  EOC 

■  Joint  Project  Manager  Guardian  (MATADRR 
Technology  Transition  Agreement  partner) 


Figure  11.  FXD  Team  and  Stakeholders, 
SPAWARSYSCENPAC,  San  Diego,  20  March  2014 
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O  other  Transition  Key  Stakehoiders 


There  are  many  organizations  and  efforts  that  have 
infiuenced  the  development  of  the  MATADRR  products. 
In  addition  to  the  requirements  generated  from  the  Fort 
Hood  and  Navy  Yard  shootings,  we  have  additional 
stakeholders  that  have  helped  shape  products,  adjust 
business  rules  and  provide  considerations  for  new 
software  adapters. 

DSEA 

The  Defense  Security  Enterprise  Architecture  (DSEA) 
is  a  sister  project  of  MATADRR,  sponsored  by  the 
OSD’s  Physical  Security  Enterprise  and  Analysis  Group 
(PSEAG),  and  represents  a  superset  -  information 
sharing  -  architecture  effort.  Its  mission  is  to  protect 
forces,  mitigate  threats,  close  protection  gaps,  and 
provide  increased  situational  awareness  by  linking  the 
disparate  physical,  personnel,  information,  industrial 
and  operations  security  domain  capabilities  across 
the  DoD  while  leveraging  other  government  agencies’ 
information.  Keystone  is  intended  to  be  a  part  of  the 
DSEA  solution  set  and  is  planned  to  be  used  in  future 
DSEA  Technical  Demonstrations. 

DHS  S&T  UlCDS 

The  Keystone  software  originated  with  the  Department 
of  Homeland  Security  (DHS)  Directorate  of  Science 
and  Technology  (S&T).  They  developed  and  fielded 
the  Unified  Incident  Command  and  Decision  Support 
(UlCDS),  a  similar  national  information  sharing 
middleware,  to  share  Common  Operational  Data  (COD) 
and  deliver  information  sharing  in  operational  support 
of  the  National  Incident  Management  System.  The 
Keystone  software  will  be  provided  to  them  at  the  end 
of  the  program. 

USPACOM/PDC 

USPACOM  has  both  a  homeland  defense  and 
deployed  mission  requirement.  USPACOM  has 
provided  key  information  about  how  the  response 
to  and  coordination  for  a  significant  event  would 
occur  inside  their  area  of  responsibility.  USPACOM 
represents  a  key  stakeholder  on  how  to  develop 
an  integrated  operational  picture  across  the  local, 
state  and  military  environment  where  they  operate. 


Considerations  such  as  the  inclusion  of  electronic  91 1 
services  were  provided  to  the  MATADRR  leadership 
from  USPACOM. 

Pacific  Disaster  Center  (PDC)  is  an  applied  science, 
information  and  technology  center,  working  to  reduce 
disaster  risks  and  impacts  on  life,  property,  and  the 
economies  worldwide.  PDC’s  products  and  services 
are  used  to  support  sound  decision  making  in  disaster 
response  and  civil-military  humanitarian  assistance 
operations,  as  well  as  in  disaster  risk  reduction, 
mitigation  and  planning.  PDC  resources  are  used 
locally  and  globally  by  disaster  and  crisis  management 
professionals,  planners  and  executive  decision  makers, 
national  governments,  regional  organizations,  and 
International  and  Non-Governmental  Organizations 
(l/NGO).  In  particular,  PDC  is  a  key  provider  of  data 
and  information  services  to  USPACOM  for  natural 
and  manmade  disasters.  PDC  leadership  met  with 
the  MATADRR  team  to  discuss  potential  information 
exchange  with  their  DisasterAWARE  product. 

TaCBRD/USEUCOM 

The  Transatlantic  Collaborative  Biological  Resiliency 
Demonstration  (TaCBRD)  is  a  collaborative  program 
between  the  U.S.  Department  of  Defense  (DoD), 
the  U.S.  Department  of  State  (DOS),  and  the  U.S. 
Department  of  Homeland  Security  (DHS).  The  Partner 
Nation  for  this  program  is  the  Republic  of  Poland. 
TaCBRD’s  objectives,  with  USEUCOM  representing 
the  operational  manager,  are  to  develop  and 
demonstrate  a  capability  for  resilience  in  countering 
a  wide-area  biological  incident  that  impacts  U.S.  and 
Partner  Nation  civilian  and  military  personnel  and  key 
infrastructure. 

Further,  the  USEUCOM  Commander  has  authorized  a 
technical  demonstration  and  series  of  exercises  using 
Keystone  to  better  connect  Host  Nation  support  to  the 
military  installations,  as  well  as,  better  connect  forward 
staging  bases  back  to  higher  command. 
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6  other  Related  Events  and  Activities 


Assessment  IPT 

An  Assessment  IPT  was  established  in  July  2013, 
following  Technology  Demonstration  #1,  to  provide  a 
cross-coordinated  focus  working  group  to  shape  the 
assessments  proposed  as  part  of  the  Independent 
Verification  Test  (IVT)  with  a  Joint  Interoperability  Test 
Command  (JITC)  assessment,  and  the  Final  Transition 
Demonstration  (FXD)  with  an  Operational  Utility 
Assessment  (OUA).  The  final  task  for  the  members 
of  the  Assessment  IPT  will  be  to  review  and  provide 
feedback  on  the  IVT  and  FXD  assessment  reports 
that  will  be  available  about  one  month  post  FXD, 
and  recommend  if  any  future  assessments  will  be 
necessary  for  the  project. 

CONORS  Working  Group 

The  Concept  of  Operations  Working  Group  (WG)  was 
established  in  late  201 2  to  bring  together  Emergency 
Management  and  Force  Protection  analysts  and 


operational  planners  from  across  the  Services  and  the 
DoD  agencies: 

■  to  help  develop  and  describe  how 
MATADRR  would  enable  greater  shared 
awareness  in  Force  Protection  and  Emer¬ 
gency  Management  operations  horizontally 
across  DoD  and  Civilian  sectors 

■  to  address  problems/gaps  of  timely  cross¬ 
service  sharing  of  Information 

■  to  help  define  how  MATADRR  would  enable 
rapid  access  to  reglonal/local  data  and 
information. 

The  CONOR  workshop  addressed  command  and 
control  arrangements  needed  to  implement  MATADRR. 
The  CONOR  described  the  processes  and  gaps 
associated  with  producing  and  rapidly  disseminating 
actionable  Information  in  a  Joint  environment. 

The  initial  WG  was  composed  of  the  attendees  listed  in 
the  following  table. 


NAME 

ORGANIZATION 

EMAIL 

EXTERNAL  ATTENDEES 

Bill  Anderson 

Software  Engineering  Institute-Carnegie 

Mellon  University 

wba@sei.cmu.edu 

Gene  Cahill 

Software  Engineering  Institute-Carnegie 

Mellon  University 

gmcahill@sei.cmu.edu 

Bob  Chapman 

Camber  Corporation 

rchapman@camber.com 

Glenn  dagger 

MARFORNORTH 

alenn.iaaaer2@usmc.mil 

Frank  Comer 

National  Geospatial-Intelligence  Agency  (NGA) 

comerf@amail.com 

Andre  Leassear 

IP2  Developer  (EM2P) 

leonard.a.leassear.ctr@mail.mil 

Heather  Keathly 

Army  G2-  ATM  IS 

heather.a.keathly.civ@mall.mil 

John  Bender 

AFNORTH  A7X  Emergency  Management 
Specialist 

john.bender@tyndall.af.mll 

Leonard  Jordan 

AFNORTH  A7X  Emergency  Management 
Specialist 

leonard.jordan@tyndall.af.mll 

LtCol  Jeff 

Hollman 

USAF  AFSFC/SFOZ 

jeffry.hollman@us.af.mil 

John  Seeley 

CNIC  N37 

john.r.seeleyl  .ctr@navy.mil 

CDR  Chris 
Gallagher 

CNIC  N37 

chris.aallaaher@navy.mil 

Bob  Whitkop 

CNIC  6.1 

robert.whitkop.ctr@navy.mil 

Ray  Roberts 

Installation  Base  Defense 

rroberts@cortek.com 
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NAME 


ORGANIZATION 


EMAIL 


Tim  Gourdine 

Installation  Base  Defense 

timothy.aourdine.ctr@us.army.mil 

aourdine.timothy@bah.com 

MSgt  Salvione 

HQ  AFSPC  Cmd  Cnt  Superintendent,  AFSPC/ 
A30C 

kathleen.salvione@us.af.mil 

Richard  Eicher 

CFM  for  1C3s  (Pentagon) 

richard.eicher@pentagon.af.mil 

MAJ  Ryan 
Leaders 

USARNORTH 

ryan.leuders@us.army.mil 

LTC  Andrew 
Gilman 

USARMY  RDECOM  Science  Advisor  to  N-NC 

andrew.l.ailman@us.army.mil 

George  Randall 

Applied  Research  Associates 

george.randall.ctr@northcom.mil 

grandall@ara.com 

MATADRR  TEAM  ATTENDEES 

Jorge  Zambrana 

USNORTHCOM  S&T  Operations  Manager/ 
Program  lead 

jorge.zambrana@northcom.mil 

Tom  Baron 

USNORTHCOM  J34 

thomas.baron@northcom.mil 

Dave  Hotop 

USNORTHCON  CTR.  Deputy  OM 

NIPR:  david.hotop.ctr@northcom.mil 

Corporate:  dhotop@camber.com 

Shawn  Schulze 

USNORTHCOM  CTR 

NIPR:  shawn.schulze.ctr@northcom.mil 
SIPR:  shawn.schulze@northcom.smil.mil 
Corporate:  sschulze@camber.com 

Mike  Spencer 

USNORTHCOM  CTR 

mspencer@camber.com 

Don  Fulloon 

ARDEC  -  Technical  Manager 

donald.w.fulloon.civ@mail.mil 

Bob  Boden 

ARDEC  -  Senior  Developer 

robert.boden5.ctr@mail.mil 

Doug  Hardy 

SPAWAR  Pacific  -  Transition  Manager 

douglas.hardy@navy.mil 

Chris  Russell 

SPAWAR  Pacific  -  Deputy  Transition  Manager 

chris.russelM  @us.army.mil 
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Program  Reference  Materials 


The  following  products  make  up  the  essential 
documentation  detailing  the  development  and  launch  of 
Keystone  and  its  accompanying  policies.  Information  is 
available  as  indicated  below  on  the  http://www.matadrr. 
ora  website  or  by  request;  please  contact  Ms.  Peggy 
West,  peggy.west@us.army.mil. 

Key  Presentations 

The  following  presentations  are  available  on  the 
MATADRR  web  site:  http://www.matadrr.org 

Information  Brief:  Provides  an  overview  of  MATADRR 
that  defines  its  operational  goals,  requirements,  and 
road  map. 

MATADRR  Transition  Brief:  Describes  the  process 
for  transitioning  the  technology,  knowledge  products, 
and  policy  recommendations  that  comprise  the 
MATADRR  program. 

MATADRR  Demonstration  Videos  R13.05  and 
R14.01: 

■  Describes  how  MATADRR  shares  information 
across  services 

■  Demonstrates  its  scalability  of  information, 
by  transferring  information  across  multiple 
Keystone  Cores 

■  Provides  examples  of  MATADRR  business 
rules 

MATADRR  FXD  VIP  Brief:  Provides  an  FXD  overview 
of  MATADRR  for  key  stakeholders. 

Doctrine,  Organization,  Training, 
Materiai,  Leadership,  Personnei, 
Facilities,  and  Policy  (DOTMLPF-P) 
Information  Sharing  Policy  Recom¬ 
mendations 

The  MATADRR  Project  will  provide  DOTMLPF-P 
change  recommendations  by  the  project  closeout. 

The  Joint  Test  Assessment  Group  (JTAG-SPAWAR 
Atlantic)  will  formally  submit  this  information  via  the 
Operational  User  Assessment  (OUA)  Report  from  the 
Final  Transition  Demonstration  (FXD).  The  following 
lists  a  few  of  the  preliminary  findings  on  unclassified 
information  sharing. 


Horizontal  Information  Sharing 

■  MATADRR  allows  bi-directional  cross-service 
information  sharing  at  the  installation  level 
utilizing  EM  /FP  systems  such  as  iP2  and 
C4IS. 

■  MATADRR  allows  one-way  cross-service 
information  sharing  at  the  installation  level 
utilizing  NIPR-SAGE. 

■  The  current  version  of  AtHoc  is  a  mass 
warning  notification  system,  not  an  EM 
system.  AtHoc  is  demonstrating  a  true  EM 
system  later  this  year. 

■  Cross-service  information  sharing  above 
installation  level  is  currently  done  ad-hoc 
using  e-mail  (and  occasionally  DMS).  Cross¬ 
service  information  sharing  above  installa¬ 
tion  level  could  be  accomplished  by  using 
NIPR-SAGE,  but  this  is  a  single  direction  — 
as  information  is  simply  posted  to  a  layer 
within  NIPR-SAGE. 

Vertical  Information  Sharing 

■  The  Department  of  the  Navy  has  imple¬ 
mented  C4IS  at  all  levels  of  command  for 
bi-directional  information  sharing. 

■  Vertical  information  sharing  in  the  Army  is 
hindered  by  higher  echelons  using  different 
EM  systems  than  are  used  at  installations. 

■  Army  installations  can  only  share  informa¬ 
tion  with  their  higher  headquarters  via  e-mail 
(bi-directional)  and  NIPR-SAGE  (one-way). 

CONOPS/CONEMP 

The  MATADRR  Joint  Concept  of  Operations 
(CONORS)  prescribes  an  automated  method  for  Force 
Protection  reporting  and  Emergency  Management 
information  sharing  through  a  back  end  application 
interface  to  improve  timeliness  and  shared  awareness. 
This  CONORS  (in  draft): 

■  Provides  information  on  the  FP/EM  auto¬ 
mated  processes 

■  Aligns  MATADRR  development  with  the 
Defense  Security  Enterprise  Architecture 
(DSEA),  National  Response  Framework 


(NRF),  National  Incident  Management 
Systems  (NIMS)  and  the  DoD  Mission  Assur¬ 
ance  Strategy 

■  Addresses  business  rules  for  data  exchange 
among  automated  FP/EM  tools  and 
systems,  resulting  in  cross-component  auto¬ 
mated  information  sharing  mission  capability 
to  address  shared  situational  awareness  of 
all  hazard  threats. 

The  MATADRR  Concept  of  Employment  (CONEMP) 
explains  how  the  MATADRR  technical  solution 
integrates  within  USNORTHCOM  assigned  missions. 
The  CONEMP  describes  the  processes  for  sharing 
information  in  a  joint  environment.  It  addresses  the 
automated  and  timely  cross  service  /  agency  sharing 
of  unclassified  information.  This  document  describes 
how  MATADRR  and  its  software  component,  Keystone, 
translates  unclassified  messages,  software  application 
data  and  Geographic  Information  Systems  (GIS)  data 
among  disparate  systems  for  Force  Protection  and 
Emergency  Management. 

IVT/FXD  Keystone  System/Software 
Requirements  Document 

The  IVT/FXD  Keystone  System/Software  Requirements 
Document  describes  the  requirements  and 
specifications  used  in  the  software  development  of  the 
Keystone  product  targeted  for  use  in  the  IVT  and  FXD 


(Keystone  R14.01).  Information  is  available  by  request. 
Please  contact  Ms.  Peggy  West,  peggy.west@ 
us.army.mil. 

Test  and  Assessment  Reports 

This  Product  Reference  Guide  was  submitted  prior 
to  the  results  of  many  of  the  Test  and  Assessment 
Reports  becoming  available  in  May  2014.  Information  is 
available  by  request.  Please  contact  Ms.  Peggy  West, 
peggy.west@us.army.mil. 

The  following  is  the  summary  list  of  MATADRR  Test 
and  Assessment  Documents  available: 

■  Joint  Test  Assessment  Group  (JTAG) 

MATADRR  Technical  Demonstration  Letter  of 
Observation  -  June  201 3 

■  JTAG  Final  Transition  Demonstration  (FXD) 

Quick  Look  Report  -  April  201 4 

■  SSC  PAG  Independent  Verification  Test  (IVT) 
Report  -  May  2014 

■  JTAG  FXD  Operational  Utility  Assessment 
(QUA)  Report -May  201 4 

■  Joint  Interoperability  Test  Command  (JITC) 
IVT/FXD  Assessment  Report  -  May  2014 


28 


Program  Reference  Materials 


Appendix  A:  Acronyms 


ACRONYM 

DEFINITION 

AAFES 

Army  and  Air  Force  Exchange  Service 

ADD 

Architecture  Description  Document 

AFNORTH 

Air  Forces  Northern 

AOR 

Area  of  Responsibility 

API 

Application  Programming  Interface 

ARDEC 

Armament  Research,  Development  and  Engineering  Center 

ARNORTH  PMO 

Army  North  Provost  Marshall’s  Office 

ASD-NM 

Assistant  Secretary  of  Defense  for  Nuclear  Matters 

ATO 

Authorization  to  Operate 

C4IS 

Command,  Control,  Communication,  Computers,  and  Intelligence  Suite 

CAD 

Computer-Aided  Dispatch 

CAP 

Common  Alerting  Protocol 

CNRSW 

Commander  Navy  Region  Southwest 

CoN 

Certificate  of  Networthiness 

COD 

Common  Operational  Data 

CONOPS/CONEMP 

Concept  of  Operations/Concept  of  Employment 

COP 

Common  Operating  Picture 

DHS 

Department  of  Homeland  Security 

DIACAP 

Department  of  Defense  Information  Assurance  Certification  and  Accreditation  Process 

DISA 

Defense  Information  Systems  Agency 

DLA 

Defense  Logistics  Agency 

DoD 

Department  of  Defense 

DOS 

Department  of  State 

DOTMLPF-P 

Doctrine,  Organization,  Training,  Materiel,  Leadership  and  Education,  Personnel, 

Facilities  and  Policy 

DSEA 

Defense  Security  Enterprise  Architecture 

DTA 

Data  Transition  Agreements 

DTRA 

Defense  Threat  Reduction  Agency 

DTIC 

Defense  Technical  Information  Center 

E2E 

End-to-End 

EDXL 

Emergency  Data  Exchange  Language 

EM2P 

Emergency  Management  Modernization  Program 

EM/FP 

Emergency  Management/Force  Protection 

EOC 

Emergency  Operations  Center 

ERDC 

Engineer  Research  and  Development  Center 

ESB 

Enterprise  Service  Bus 
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ACRONYM 

DEFINITION 

FEMA 

Federal  Emergency  Management  Agency 

FXD 

Final  Transition  Demonstration 

GIS 

Geographic  Information  Systems 

GOTS 

Government  Off-the-Shelf 

HTTPS 

Hypertext  Transfer  Protocoi  Secure 

lAP 

Incident  Action  Plan 

lATO 

Interim  Authority  to  Operate 

ICD 

Interface  Control  Documents 

ICP 

Incident  Command  Post 

ICS 

Incident  Command  System 

IMCOM 

Installation  Management  Command 

l/NGO 

International  and  Non-Governmental  Organizations 

iP2 

Installation  Protection  Integration  Piatform 

IPAWS 

Integrated  Public  Alert  and  Warning  System 

IPT 

Integrated  Product  Team 

IT 

Information  Technoiogy 

IV&V 

Independent  Verification  and  Validation 

IWS 

Integrated  Web  Services 

JAR 

Java  Archive 

JAXB 

Java  API  for  XML  Binding 

JEM 

Joint  Effects  Model 

JITC 

Joint  interoperabiiity  Test  Command 

JMS 

Java  Messaging  Services  (Java  API) 

JPM 

Joint  Project  Manager 

JPMG 

Joint  Project  Manager  Guardian 

JTAG 

Joint  Test  Assessment  Group 

JWARN 

Joint  Warning  and  Reporting  Network 

KML 

Keyhoie  Markup  Language 

MAC  II 

Mission  Assurance  Category  Levei  li 

MATADRR 

Mission  Assurance,  Threat  Aiert,  Disaster  Resiliency  and  Response 

NETCOM 

Network  Enterprise  Technoiogy  Command 

NCR 

National  Capital  Region 

NGB 

National  Guard  Bureau 

NIEM 

National  Information  Exchange  Model 

NIMS 

National  Incident  Management  System 

NIPR  SAGE 

Non-Secure  Internet  Protocol  Router  Situational  Awareness  Geospatial  Enterprise 
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ACRONYM 

DEFINITION 

OASIS 

Organization  for  the  Advancement  of  Structured  Information  Standards 

OUA 

Operational  Utility  Assessment 

PDC 

Pacific  Disaster  Center 

POA&M 

Plan  of  Action  &  Milestones 

PRO 

Product  Reference  Guide 

PSEAG 

Physical  Security  Enterprise  and  Analysis  Group 

PUB/SUB 

Publish  and  Subscribe 

REST 

Representational  State  Transfer 

S&T 

Science  and  Technology 

SA 

Situational  Awareness 

SDD 

System-Subsystem  Design  Document 

SDK 

Software  Development  Kit 

SEIWG 

Security  Equipment  Integration  Working  Group 

SIP 

System  Identification  Profile 

SOA 

Service  Oriented  Architecture 

SOAP 

Simple  Object  Access  Protocol  (XML  protocol) 

SPAWAR 

Space  and  Naval  Warfare 

SPAWARSYSCENPAC 

SPAWAR  Systems  Center  Pacific 

SSL 

Secure  Sockets  Layer 

TaCBRD 

Transatlantic  Collaborative  Biological  Resiliency  Demonstration 

TCP 

Transmission  Control  Protocol 

TNT 

Technology  and  Transition 

TTA 

Technology  Transition  Agreement 

TTP 

Tactics,  Techniques  and  Procedures 

UlCDS 

Unified  Incident  Command  and  Decision  Support 

USEUCOM 

U.S.  European  Command 

USFF 

United  States  Fleet  Forces  Command 

USMTF 

United  States  Message  Text  Format 

USNORTHCOM 

U.S.  Northern  Command 

USPACOM 

U.S.  Pacific  Command 

WDSL 

Wireless  Digital  Subscriber  Line 

WebEOC 

Web  Based  Emergency  Operations  Center 

WG 

Working  Group 

XML 

Extensible  Markup  Language 
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Postscript 


The  MATADRR  Transition  Management  Team  would  like  to  thank  all  of  the  contributors  to  this  document. 
We  hope  that  you  found  this  document  contained  concise,  valuable  information  about  the  Product  and  its 
Transition  State  as  of  June  2014.  Further,  we  hope  that  it  provided  useful  information  about  where  to  go 
and  who  to  contact  for  additional  product  information.  If  you  have  feedback  or  ideas  on  how  to  improve 
this  report,  or  have  general  comments  or  questions  about  the  project,  or  specific  questions  about  the 
products  named  herein,  please  email:  peggy.west@us.army.mil  or  call:  619-553-6899.  For  an  alternate 
point  of  contact,  please  email:  douglas.hardy@navy.mil  or  call:  619-553-5410. 
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